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(57) Abstract: This invention relates to the field of IP telephony. More particularly, this invention is a method and system for select- 
ing gateways for routing calls through a packet-based telecommunications network interconnected with a public telecommunications 
network. This invention is a method and system for dynamically detecting available gateways (1 10a, 1 10b), dynamically removing 
failed or unavailable gateways (1 10a, 1 10b), and automatically recovering failed or unavailable gateways after a predetermined pe- 
riod of time. An embodiment of this invention comprises two user agents ( 102, 103) within two telephony systems (1 14a, 1 14b) that 
are connected to an IP network (1 12); a plurality of gateways (1 10a, 1 10b); an IP telephony proxy server ( 106); an IP redirect server 
(104); and a network management system (108). 
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METHOD AND SYSTEM FOR DYNAMIC GATEWAY SELECTION 
IN AN IP TELEPHONY NETWORK 



10 BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates generally to the field of TP telephony, and more particularly 
to a method and system for selecting gateway(s) for routing calls through a packet-based 
telecommunications network interconnected with a public telecommunications network. 
1 5 Acronyms 

The written description herein uses a number of acronyms to refer to various services, 
messages and system components. Although generally known, use of several of these acronyms 
is not strictly standardized in the art. For purposes of this discussion, several acronyms will be 
defined as follows: 

20 Dynamic Gateway Selection (DGS) - a process employed by a network server and a 

Redirect Server (RS) to allow calls to be routed to an egress gateway. 
Egress (Destination) and Ingress (Origination) Gateways - gateways connecting an 
internet protocol network to a PSTN, PBX or other network. 

Network Management System (NMS) - performs a variety of functions- including 
25 receiving and storing status changes to destination or egress gateways. 

Description of the Prior Art 

Internet telephony provides real-time delivery of voice, and other multimedia data, 
between two or more parties across a network employing Internet protocols (IP). Internet 
telephony is session-based rather than connection-based. That is, Internet telephony uses virtual 
30 connections or circuits to pass data between two nodes. These connections between the nodes 
are termed "virtual circuits" to distinguish them from dedicated circuits of conventional 
networks. 

i 
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While IP telephony offers benefits to both users and carriers in terms of costs and 
versatility of media carried, there are a substantial amount of traditional telephones being 
serviced by the Public Switched Telephone Network (PSTN). The PSTN provides users with 
dedicated, end-to-end circuit connections for the duration Of each call. Circuits are reserved 
5 between an originating switch and a terminating switch based on a called party number. 

However, because of the popularity of the Internet, many public telecommunications 
networks now carry significantly more TP data traffic than voice data traffic. Public 
telecommunications networks, optimized for voice traffic, are ill-equipped to handle increasing 
data traffic volumes. The growth in IP data traffic coupled with customer demands for integrated 
10 voice and data services at lower costs has led to the adoption of IP as the preferred protocols for 
carrying both voice and data traffic between originating and terminating switches of the public 
telecommunications network. 

Accordingly, in order for IP based telephony services to become broadly accepted by 
users of traditional telephones, it is necessary to interface the IP telephony network with the 
15 existing PSTN and with private PBX phone networks. To permit this mode of operation,. a 
packet-based network, such as the Internet, must interface directly with public telephone 
networks and operate as a bridge between originating and destination switches of such networks. 

Media streams which originate from a public network must be capable of being 
transported through the packet-switched IP network and terminate at the same or different public 
20 network. This type of interfacing is performed by gateways which interface the signaling and 
bearer paths between the two networks. Therefore, Internet gateways perform code and protocol 
conversion between two otherwise incompatible networks to provide links necessary to send 
packets between the two different networks and thus make network-to-network connections 
possible. To assure overall system reliability it is crucial that the gateways arc reliable and their 
25 availability, especially destination or egress gateways, be monitored for quickly and efficiently 
selecting an available gateway. 

SUMMARY OF THE INVENTION 

In accordance with the principles of the invention, a method and system are provided by 
30 which an egress (i.e., destination) gateway is dynamically selected to establish a communication 



WO 01/84794 




PCT/USOl/14272 



session over a path supported ax least in pan by an IP telephony network and a PSTN. PBX or 
other network. A redirect server (RS) in concert with a network management system (NMS) 
employs a gateway selection methodology which includes recording egress gateways which are 
not available due to several reasons, such as having timed out. or having a malfunction, i.e.,. 
5 failure status. 

In one embodiment of the present invention, a method is provided for dynamically 
selecting an egress gateway to allow a call to be completed in a communication session over a 
path supported at least in part by an IP telephony network and a PSTN. PBX or other network 
The IP telephony network includes a plurality of ingress and egress gateways, at least one 
10 Session Initiation Protocol (SIP) proxy server (SPS) and at least one redirect server (RS). A 
dynamic gateway selection (DOS) feature is always active and is typically invoked whenever a 
source user agent (SUA) initiates a call attempt by sending a session participation request to the 
SPS. 

The preferred method generally includes the steps of: receiving a call setup request at the 
1 5 SPS from the SUA - The SPS forwards the request to the RS to obtain information of destination 
gateways. The R responds to the SIP session participation request with either a redirection 
response or a request failure response. The RS redirection response includes a routing list. The 
routing list is a list of egress (i.e., destination) gateways that arc determined to be in-service.. 
Upon receipt of a redirection response from the RS. the SPS proxies the session participation 
20 request to a first destination gateway in the routing list. Otherwise, the RS returns a failure 
response which is sent to the SUA. The failure response is an indication that there are no 
destination gateways having an in-service status. 

When the SPS proxies the request to a destination gateway, the SPS waits for a final 
response from the selected destination gateway. The SPS will either receive a final response or 
25 time-out. When the SPS receives a final response from the destination gateway, the SPS proxies 
the final response to the SUA, awaits an acknowledgment and proxies the acknowledgment. 
Otherwise, when the SPS times-out waiting for a final response from the destination gateway, 
the SPS re-sends the request a predetermined number of times. I f the SPS times-out for a final 
time, the SPS sends the session participation request to the next destination gateway in the 
30 routing list provided by the RS. 
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The process of sending a request a predetermined number of times is repeated for the 
next destination gateway in the routing list until one of the following occurs: (I) a success 
response is returned; (2) the SPS times-out waiting for a final response, as described above with 
respect to the first destination gateway in the routing list: (3) the SPS receives an unsuccessful 
5 final, non-server failure response from the currently selected destination gateway; or (4) the 
destination gateway returns a server failure response, in which case the SPS informs the RS of 
the destination gateway failure. 

In case of the second to fourth situations, the SPS sends the session participation request 
to other destination gateways in the routing list provided by the RS. For each destination 

1 0 gateway that returns a gateway failure response to the SPS. the destination gateway is recorded 
as an out-of-service destination gateway in the RS and is dynamically removed from the routing 
list. Therefore, subsequent requests are not sent to destination gateways which are recorded as 
out-of-service destination gateways in the RS until after a predetermined amount of time. After 
the predetermined amount of time has elapsed, the RS automatically recovers failed or out-of- 

1 5 service pathways and issues a report to a network management system (NMS) indicating that the 
destination gateway is back in service. Table structures, stored within the RS. are updated on 
a real-time basis when it is determined that a gateway is out-of-service or back in-service. When 
the session participation request has been sent to all destination gateways and no successful 
response is received, the SPS returns a final response to the originating agent or calling party 

20 indicating that a call cannot be made. r 

In an alternative method, availability of destination gateways is determined using a ping 
method. In this method, gateway availability is determined by sending at least one packet to 
each destination gateway to ascertain whether the destination gateway is available, or in-service. 
If the destination gateway is in-service, it transmits an ACK message. If an ACK message is 

25 not received after a predetermined period of time, the destination gateway (DGW) is determined 
to be unavailable. The ping method preferably queries each destination gateway one-by-one and 
updates gateway information tables by recording the status of each destination gateway. 

The present invention thereby provides several functions, including: (1) dynamic 
detection of failed and unavailable gateways; (2) dynamic removal of failed and unavailable 

30 gateway(s) from a routing list, gateway information table, etc.. after a predetermined period of 
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time; and (3) automatic recovery of failed and unavailable gateways by updating gateway status 
tables after a predetermined period of time. 

RPTF.F DESCRIPTION OF THE DRAWINGS 
5 Various preferred embodiments are described herein with reference to the accompanying . 

drawings, in which: 

FIG. 1 is a block diagram of a preferred embodiment of the present invention; 

FIG. 2 is a flowchart illustrating signaling and call setup procedures according to the 

embodiment of FIG. 1 ; 

10 pig 3 is a call flow diagram illustrating the signaling and call setup procedures 

according to the embodiment of FIG- 1 ; and 

FIG. 4 is a flowchart illustrating an alternate embodiment of the present invention. 

DETAILED DESCRIPTION OF THE P REFERRED EMBODIMENTS 
1 5 Preferred embodiments of the present invention will now be described with reference to 

the figures where like reference numbers indicate identical or similar elements. It will be 
apparent to persons skilled in the relevant art that the present invention can operate on many 
different types of networks without departing from the scope of the present invention. In the 
preferred embodiments described herein, the I? telephony network is preferably the Internet. 
20 Other examples of networks which could be used include leased lines, frame relay, and 
asynchronous transfer mode (ATM) networks. 

The present invention provides a method and system for selecting an egress or 
destination gateway to establish a communication session over a path supported at least in part 
by an IP telephony network, such as a WAN, and a PSTN, PBX or other network. The method 
25 further determines the status of a destination gateway, particularly, as being cither in-service or 
out-of-service. and automatically brings a destination gateway back into service from an out-of- 
service state after a predetermined amount of time. 

Referring now io the drawings, and first to FIG. 1, a system according to a preferred 
embodiment of the present invention is designated generally by reference numeral 10. System 
30 1 0 is a telephony network system and incl udes a first public switched telephone network (PSTN) 
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, ,4a which interfaces .o an IP telephony network or internet ,12. The Interne, 1 ,2 is further 
interfaced to a second PSTN 1 1 4b. The first PSTN 1 1 4a includes a source user agent (SUA) 
,02 ie ongitatins agent, which originates a session participation request. The second PSTN 
, ,4b includes a called party destination user agent (DUA. 103). The Interne, 1 12 includes a 
redirect server (RS) 104. an SIP proxy server (SPS) 106. a Network Management System (NMS) 
,08 and destination gateways (DOWs) ,10a, 110b. while only two DGWs are shown, one of 
ordinary skill in the an will recognize that additional DGWs may be provided. The RS 104 
suppons a gateway management taction which .racks tire stems of the DGWs. The NMS 10* 
receives and stores all status changes regarding DGWs 1 10a. 1 10b. Status changes are reported 
U> tire NMS 108 by the RS 104 via the SPS 106. SPS 106 acts as both a server and chent for rhe 
purpose of making reouesrs on behalf of other clients. SPS 106 provides proxy server and 
gateway resource management functions. SPS 106 may be a SIP proxy server or an H.323 
gatekeeper. 

-me method of the present invention (i.e., dynamic gateway selection (DGS) and 
removal) is performed by the SPS 106 and RS 104 in context with the NMS 108 in order to 
allow calls to be routed to one of the DGWs 110a , 1 10b. The dynamic gateway selection and 
removal feature is particularly invoked upon receipt by the RS 104 of a session participation 
request. The SUA 102 initiates a call attempt to transmit the session panicipation request to the 
SPS 106. Accordingly, an attempt is made to establish a communication session between the 
SUA 102 located in the first PSTN 1 14a and the called party destination device (DUA) 103 
located in the second PSTN 114b. PSTN 1 14a and 1 14b are bridged via the Internet ; . 

FIG. 2 is a flowchart illustrating the call routing logic for establishing a communication 
session in accordance with the methodology of the present invention. At step 702, a user 
initiates a call attempt by sending a session participation request (i.e., an INVITE request) to the 
SPS 106. When the INVITE request is an initial request, the SPS 106 forwards the initial 
INVITE request to the RS 1 04 for routing instructions at step 704. At step 705. it is determined 
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whether there is at least one DOW that can satis* the request. If so. at step 706. the RS 104 
responds to the SPS 106 query with arouting list. i.e.. a list of candidate DGWs that can handle 
the call. The RS 104 supplies the routing list from a gateway information table stored therein. 
In the event the RS 104 determines that there are no DGWs that can satisfy the INVITE 
5 request, at step 705, a request failure response is returned to the SUA 102. at step 707. Upon 
receiving the routing list, the SPS 106 proxies the INVITE request to one of the DGWs ilOa, 
110b. At step 708. the SPS 106 selects the first DGW 1 10a in the routing list to determine its 
serviceability and/or availability status. Steps 710 and 712 determine whether the currently 
selected DGW 1 10a from the routing list is in a failure state or has timed out. Specifically, at 
10 step 710, a determination is made concerning whether the DGW 1 10a returns a failure response 
(i.e., out-of-service response). If there is a failure response at step 710, the SPS 1 06 reports the 
gateway fai-e- the RS 1 04 at step 714. The RS 104 marks the selected DGW 110a as an out- 
of-servic, Uestirarion gatexvay in a gateway information table stored in the RS 104. at step 716. 

In addition, the SPS 1 06 sends a message, (i.e., Simple Network Management Protocol 
(SNMP) trap) to the NMS 108 indicating a destination gateway failure. The SPS 106 then 
selects the next DGW 11 0b in the routing list, at step 7 1 8. Control then returns to step 710 to 
determine the availability of the next selected DGW 1 1 0b; that is, whether the next selected 
gateway 1 10b is in a failure state or has timed out. If the next selected DGW 1 10b returns either 
a failure response at step 710, or times-out at step 712, then steps 714-718 are repeated. In short, 
the process of selecting a gateway from the routing list and determining whether it is in a failure 
state or has timed out is repeated until a DGW is found from the routing list which accepts a caU~ 
with a success response at step 720. When a success response is received, the SPS 106 forwards 



15 



7 



WO 01/84794 



PCT/US01/14272 



10 



15 



die response to the calling user SUA 102 at step 722. The media stream for the call is then set- 
up at step 724 to establish a communication link between the SUA 1 02 and DUA 103. 

FIG. 3 is a call routing flow diagram illustrating in greater detail the call routing logic 
procedure described above with reference to FIG. 2. Table I below lists the INVITE required 
parameter fields in the preferred embodiment when a SUA 102 initiates a call attempt by sending 
a session participation request (i.e.. an INVITE request) to the SPS 106 (See FIG.1, item 1 and 
FIG. 3, step *'a"). 

Table 1 



Parameter 


Usage 


Request- Line 


Contains the method (e.g., INVITE), Request Uniform Resource 
Identifier (i.e., Request-URI) of the SPS and protocol version 


To 


Contains the address of the recipient of the request 


From 


Contains the address of the initiator of the request 


Call-ID 


Uniquely identifies the invitation 


Cseq 


Contains the request method and a decimal sequence number 
chosen by the requesting client, unique within a single value of 
the Call-ID 


Via 


| Indicates the path taken by the request so far 



The SIP INVITE is addressed to the called party DUA 1 03 at a proxy address at the SPS 
106. The SIP INVITE specifies the real IP address of the DUA 103. Upon receipt of the SIP 
INVITE, the SPS 106 sends a 100 trying message to the ingress or origination gateway 105 
(FIG. 3, siep "b")- Table 2 lists the mandatory fields associated with the 100 trying response 
message in the preferred embodiment. 

Table 2 



Parameter 



Usage 
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Status-Line 


Status Code = 100. Reason phrase and protocol version 


To 


Content copied from the original request message 


From 


Content copied from the original request message 


Call-ID 


Content copies from the original request message 


Cseq 


Content copies from the original request message 


Via 


Indicates the path taken by the request so far. Add the received- 
tag parameter if the previous address is incorrect in the via header 
field 



TheSPS 106 counts the number of INVITE requests received. When a received request 
message does not contain a route header field, it is determined to be an initial INVITE request 
message. In such a case, the SPS 106 performs the following steps: (1) if a Topmost Via Header 
(TVH) source address is incorrect, adds a "Received" parameter (or replaces me existing one if 
there is one) with the source package to the Via header field inserted by the previous hop; (2) 
generates an internal Call-ID; or (3) forwards the requested message to the RS 1 04 (See FIG. 1, 
item 2 and FIG. 3, step "c"). Table 3 lists the required fields in the RS TNVITE request message. 

Table 3 



Parameter 


Usage 


Status-Line 


Content copied from the original request message 


To 


Content copied from the original request message 


From 


Content copied from the original request message 


Call-ID 


Internally generated Call-I 


Cseq 


Content copied from the original request message 


Via 


Add the received tag 



In response to receiving the RS INVITE request message from the SPS 106. the RS 104 
performs the following: (1) counts the number of INVITE messages received; and (2) determines 
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that the user portion of Request Uniform Resource Identifier (i.e.. (Request-URI) is less than or 
equal to 1 5 digits and does not contain a leading 0 or I . The gateway information table stored 
in RSI 04 is used to create an updated routing list. 

For example, when a gateway address is marked as out-of-service in the gateway 
information table stored in RS 104 and its associated time value is zero, the gateway address is 
not added to the routing list. When the gateway address is marked as out-of-service in the 
gateway information table and its associated time value is greater than the current absolute RS 
time, the gateway address is not added to the routing list. When the gateway address is marked 
a* out-of-service in the gateway information table and its associated time value is less than or 
equal to the current absolute RS time, the gateway address is added to the routing list and the 
gateway address is marked as in-service in the gateway information table. The RS 1 04 also sends 
a message, i.e., the Simple Network Management Protocol (SNMP) trap, to the NMS 108 
indicating that the DGW is in-service. If there is only one gateway in the routing list, the RS 104 
will send a 302 response message back to the SPS 106 (See FIG. 1, item 3 and FIG. 5. step "d"). 
The RS 104 increments a counter which counts the number of 3xx messages sent. Table 4 lists 
the required fields in the 3xx (302 in the present case) response message and an example of the 
contact address list. 

Table 4 



Parameter 


Usage 


Status-Line 


Status Code - 302, Reason phrase and protocol version 


To 


Content copied from the Original INVITE request 


From 


Content copied from the Original INVITE request 


Call-ID 


Content copied from the Original INVITE request 
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Cseq 


Patent corned from the Original INVITE request 


Via 


Content copied from the Original INVITE request 


Contact 


Multiple gateway addresses 
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Table 5 lists the required fields in the SNMP trap message to the NMS. 



Table 5 



Parameter 


Usage 


Protocol Data 
Unit (PDU) Type 


Indicates that this is a Trap PD 


Enterprise 


Identifies the network-management subsystem that generated 
the trap. Its value is taken from sysObjectID in the system 
Group 


Agent-addr 


The IP address of the object generating the trap 


Generic-trap 


6 = enterpriseSpecific, This value signifies that the sending 
protocol entity recognizes that some enterprise-specific event 
has occurred. The specific-trap field indicates the type of 
trap 


Specific-trap 


A code that indicate more specifically the nature of the trap 


Time-stamp 


The time between the last (reinitialization of the network 
entity that issued the trap and the generation of the trap 


Variable bindings 


The address of the gateway that returned the 5xx response 
and status (in-service) ! 



In the case where there is more than one gateway in the routing list, the RS 104 sends a 
300 response message, instead of a 302 response message for a single gateway, back to the SPS 
106. For a 300 response, the RS 1 04 also counts the number of 3xx responses sent. Table 6 lists 
the required fields in the 300 response message and an example of the contact address list. 
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Table 6 



Parameter 

Status-Line 


Usage 

Status Code - 300. Reason phrase and protocol version 


To 


Same as the original INVITE 


From 


Content copied from the Original INVITE request 


Call-ID 


Content copied from the Original INVITE request 


Cseg 


Content copied from the Original INVITE request 


Via 


Content copied from the Original INVITE request 


Contact 


Multiple reachable addresses _ 



The SPS 106 counts the number of routing responses received from the RS 104. The 
SPS 106 sends an INVITE to the first DGW 110a, and inserts the "user=phone" header in each 
contact list address (See FIG. 1, item 4 and FIG. 3, step «e»). Table 7 lists the required fields of 
the INVITE request sent from the SPS 106 to the DGW 1 10a. 

Table 7 



Parameter 


Usage ■ 


Request-Line 


Contains the method (e.g., INVITE). Request-URI using the 
gateway from the top of the unused contact list and protocol 
version — 


To 


Content copied from the original request message 


From 


Content copied from the original request message 


Call-ID 


Content copied from the original request message 


Cseq 


Content copied from the original request message 


Via 

Record Route 


Add the NS URL to the top 

Request-I JRI of the NS 
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The SPS 106 may receive a 100 trying response (see FIG. 3, step "f ) or a 180 ringing, 
response from the DG W 1 1 0 a (See FIG. 3. step "a"). Table 8 lists the required fields of the 180; 



ringing response. 



10 



Table 8 



Parameter 


Usage 


Status-Line 


Status Code = 180, Reason phrase and protocol version 


To . 


Same as the original INVITE request plus tag 


From 


Same as the INVITE request sent to the Egress Gateway 


Call-ID 


Same as the INVITE request sent to the Egress Gateway 


Cseq 


Same as the INVITE request sent to the Egress Gateway 


Via 


Same as me INVITE request sent to the Egress Gateway 



After receiving the 180 ringing response from the DGW 1 10a, the SPS 106 removes 
itself from the top of the Via field, re-starts the invite User Agent (UA) timer if it exists, and 
forwards the 180 ringing response to the ingress gateway (See FIG. 3, step "g"). The response 
message is sent to the address indicated in the Via header field. Table 9 lists the required 
message elements. 

Table 9 



Parameter 


Usage ; 


Status Line 


Content copied from the 1 80 response received from the gateway 


To 


Content copied from the 180 response received from the gateway 


From 


Content copied from the 180 response received from the gateway 


Call-ID 


Content copied from the 180 response received from the gateway 


Cseq 


Content copied from the 180 response received from the gateway 


Via 


Content copied from the 180 response received with the removal 
oftheNSURL 
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tmvttF resnonse (i e ^00 OK response) from the DGW 1 10a (See 
The SPS receives an INVl 1 b response ^i.c. ~w v v 

FIG. 3. step "hi")- Table 10 lists the required fields in the INVITE message. 

Table 10 



Parameter 


Usage 


Status Line 


<?tatn<; Code - 200, Reason phrase and protocol version 


To 


Same as the ordinal INVITE request plus tag 


From 


Same as the INVITE request sent to the Egress Gateway 


Call-ID 


Same as the INVITE request sent to the Egress Gateway 


Cseq 


Same as the INVITE request sent to the Egress Gateway 


Record Route 


Request-URI of the NS — 


Conract 


The reachable address of the Egress Gateway 



After receiving the 200 OK response from the DGW 1 10a, the SPS 106 performs the 
following step,: T) cancels the invite UA timer, if it exists; (2) removes the SPS URL from the 
Topmost Via Header (TMVH) field; (3) adds the next hop's Request-URI at the top of the 
record-route header field when either of the following conditions are met: a) there is no contact 
header field in the 200 OK response, or b) the SPS URL is on the top entry of the record-route 
header field; (4) counts the number of 200 INVITE responses sent by the SPS 106; and (5) the 
SPS 106 starts the ACK timer. The SPS 106 forwards the INVITE response (i.e., 200 OK 
response) to the ingress gateway (See FIG. 3, step "hi")- Table 1 1 lists the required headers in 
the INVITE response. 
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Table 1 1 



Parameter 


Usage 


Status-Line 


Status Code = 200. Reason phrase and protocol version 


To 


Same as the original INVITE request plus tag 


From 


Same as the INVITE request sent to the Egress Gateway 


Call-ID 


Same as the INVITE request sent to the Egress Gateway 


Cseq 


Same as the INVITE request sent to the Egress Gateway 


Via 


Content from the INVITE request sent to the Egress Gateway 


Record Route 


Request-URIoftheNS 


Contact 


The reachable address of the Egress Gateway 



The SPS 106 receives an ACK response from the ingress gateway and stops the ACK 
timer. The SPS 106 counts the number of ACK response messages received by the SPS 106. 
Table 12 lists the required headers of the ACK response (See Fig. 3, step "k"). 

Table 12 



Parameter 


Usage 


Request-Line 


Contains method (e.g., ACK), Request-URI of the NS and 
protocol version 


To 


Same as the original INVITE plus the tag 


From 


Same as the original INVITE 


Call-ID 


Same as the original INVITE 


Cseq 


Same sequence number as the original INVITE 


Via 


UA originated 



The received ACK response may contain a route header field. The SPS 106 either 
proxies the ACK response using the address in the route header or uses the address in the "To" 
header to determine whether to proxy the ACK response or consume the ACK response. The 
ACK response will be consumed when the "To" header address is equal to the SPS address, and 
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«o whon the SPS 106 determines thai the ACK 
no route header exists in the ACK response. When the bPb 

proxied. the SPS 106 performs the following: U) the SPS 106 adds the 
of the Via field; (2) the SPS 106 removes the top address from the 
the address located at the top of the route header 



response should be 
ACKs address to the top 

route header field: (3) the Request-URI is set to 

• ~*a~a to the- DGW 1 1 0a based on the top address in the 
field- and (4) the ACK message is torwarded to the DGW i lua 

route header field if it exists or based on the call context's DGW information (See FIG. 3. step- 
"H Accordingly, the DGW 1 10a is selected as the available gateway for completing the call. 
If the DGW 1 10. is determined to be unavailable, the same method outlined above is used to 
determine if DGW 1 10b is available. If neither DGW is available, a message is sentto the SUA 

t . j T „uu i a Kets T he narameters of the ACK. request message 
102 that the call cannot be completed. Table 13 lists the paramex 

sent to the DGW 110a. 

Table 13 



Parameter 


Usage 1 


Request-Line 


Contains method (e.g., ACK), Request-URI is copied from the 
too list of Route header field and protocol version 


To 


Content copied from the ACK received from the Ingress 
Gateway — — 


From 


Content copied from the ACK received from the Ingress 
Gateway . — 


Call-ID 


Content copied from the ACK received from the Ingress 
Gateway . 


Cseq 


Content copied from the ACK received from the Ingress 
Gateway . . — ■ - 1 


Via 


UA originated with the NS URL added to the top of Via field 



In anotner prcxcii^u. - 

embodiment gateway availability is determined by sending at leas, one paeket to each 
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destination gateway to ascertain whether the destination gateway is available, or in-service. 
Accordingly, if the destination gateway is in-service, it transmits an ACK message. If an ACK 
message is not received after a predetermined period of time, the DGW is determined to be 
unavailable. The ping method preferably queries each destination gateway one-by-one and 
5 updates a gateway information table by recording the status of each gateway. For example, if 
the ACK message is received, the DGW is then checked to determine if it is available. If it is 
available, its address is stored in a gateway information table, and the process repeats for the next 
DGW. 

FIG. 4 is a flowchart illustrating the methodology of an alternate embodiment of the 
10 present invention, i.e.. the ping method. A counter is initialized at step 800 to indicate the 
currently selected destination gateway from the routing list (i.e., i=l to the number of gateways 
in the routing list). In step 802, a message is transmitted from a server (e.g. proxy server, 
redirect server) to the ith destination gateway for the purpose of obtaining a response. In step 
804 the server awaits a response from the ith destination gateway. Step 806 is a determination 

15 step to determine whether a response was received from the ith destination gateway. If a 
response is not received within a predetermined amount of time, the process continues to step 
807 where the ith gateway is marked as out of service or unavailable. In step 808, it is 
determined whether there are additional destination gateways to check from the routing list. If 
not, the process terminates at step 810. Otherwise, the counter is incremented to select a 

20 succeeding destination gateway from the routing list at step 812. 

Steps 802-806 are then repeated to check the response and/or availability of the 
succeeding (i.e. ith + 1) destination gateway from the routing list, (fit is determined at step 806 
that a response is received within the predetermined time, the process continues to step 814 
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where h is men further derermmed — «- *— *» " " " 

not „ me destination gateway is no, available, rhe process returns to step 807 where the 
destination gateway is marked as out of service or unavailable, in step 808. it is then determined 
wl «her there ate additiona, destination gateways to check horn the routing lis,. If so. steps 802- 
gOo are repeated fot tine succeeding destination gateway. Otherwise, if it is defined at *ep 
114 titatthe responding destination gateway is availabie, the process continues a. *ep 816 where 
Una destination gateway is marked as avai,able in a gateway status tabie. The process returns to 
Sep 808 ,o determine if there are additional destination gateways ,„ be checked in the routing 
list. 

Wha, has been described herein is merely illustrative of the application of tire principles 
of the present invention. For example, the functions described above for operating tire present 



T illustration purposes only. Other arrangements and methods may be 
,pleme D ..d b- those skilled in the art without departing from .he scope and spirit of the 



invention 

im 
invention. 
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WH AT TS CLAIM EDIS: 

1 l. A method for routing calls to a desiinaxion gateway to establish a communication 

2 session call in a telecommunications network over a path supported at least in part by a telephone 

3 network and an IP network, said IP network including a plurality of ingress and destination 

4 gateways, at least one proxy server, and at least one redirect server (RS), said method comprising 

r 

5 the steps of: 

. a) receiving a call setup request at the at least one proxy server from a source user 



6 



7 agent; 

8 b) forwarding the received call setup request to the redirect server to obtain 

9 routing information; 

I o c) responding to the forwarded call setup request received at the redirect server 

II by returning said routing information or a request failure response; 

1 2 d) proxying the call setup request by the at least one proxy server to a destination 

1 3 • gateway selected from said routing information upon receiving the routing information from the 

14 redirect server; 

q 5 e) upon proxying the call setup request by the at least one proxy server to the 

1 6 selected destination gateway, waiting for a response at the at least one proxy server from the 

17 selected destination gateway; 

1 a f) upon said at least one proxy server receiving the response from the selected 

. 1 9 destination gateway within a predetermined time, establishing a communication session using 

20 said selected destination gateway; and 

21 g) if the response i s not received within the predetermined time, sending the 

22 call setup request to a succeeding destination gateway selected.from the routing information. . 
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1 . 2 . The method as claimed in claim I . further comprising repealing steps (d) to (g) 

2 until a destination gateway is determined to be available for establishing said communication 

3 session or until all destination gateways from said routing information have been determined to 

4 be unavailable. 

3 . The method of claim 1 , further comprising the steps of: 

2 • recording a destination gateway status as unavailable if response from said 

3 destination is not received within the predetermined time; and 

4 recording a destination gateway status as unavailable if the response from said 

5 selected destination indicator the destination gateway is unavailable. 

1 4. The method as claimed in claim 3, wherein said step of recording records 

2 said destination gateway status as out-of-service in a gateway information table stored within 

3 the RS. 

! 5. The method as claimed in claim I, wherein said step of receiving a call setup 

2 request at the at least one proxy server from a source user agent includes the step of addressing 

3 said call setup request to a proxy address of the at least one proxy server. 

1 6. The method as claimed in claim 1 . wherein said step of receiving a call setup request 

2 at the at least one proxy server from a source user agent includes the step of counting a number 

3 of received requests subsequent to said call setup request at the at least one proxy server. 
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1 7. The method as claimed in claim 1 - wherein rhe at least one proxy server 

2 comprises a Session Initiation Protocol (SIP) proxy server. 

1 8. The method as claimed in claim I . wherein the at least one proxy server 

2 comprises an H.323 gatekeeper. 

1 9. The method as claimed in claim 1 , wherein said step of responding to the 

2 forwarded call seiup request from said at least one proxy server received at the RS includes 

3 determining the status of a group of destination gateways. 

1 10. The method as claimed in claim 9, wherein the status of each of said group or 

2 destination gateway is one of in-service and out-6f-service. 

1 11 . The method as claimed in claim 1 0, wherein if the destination gateway status is 

2 recorded as out-of-service in a gateway information table and its associated time value is greater 

3 than a current absolute RS time, the gateway address is not added to a routing list of said routing 

4 information. 

1 12. The method as claimed in claim 1 0. wherein if the destination gateway status is 

2 recorded as out-of-service in a gateway information table and its associated time value is less 

3 than or equal to the current absolute RS time, the gateway address is added to a routing list of 

4 said routing information and recorded as in-service. 
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1 3. The method as claimed in claim 10. funher including the step of sending a 
message from the RS to a network manager to record the status of a destination gateway. 

H. The method as claimed in claim I. further comprising the steps of forwarding a 
request failure response to the source user agent upon receiving the request failure response froth 
the at least one proxy server, and terminating the communication session. 

15. The method as claimed in claim I, further comprising the step of re-sending the 
call serup request to the selected destination gateway a predetermined number of times when the 
response is not received within the predetermined time. 
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1 1 6. A system for allowing a call to be completed in a communication session between 

2 a calling party and a called party, which comprises: 

3 . a first telephony system including at least one service user agent (SUA); 

4 a second telephony system including at least one destination user agent (DUA); : 

5 an IP network connected between said first and second telephone systems, 

6 a plurality of ingress gateways for interfacing said TP network to said first 

♦ 

7 telephony system; 

8 a plurality of egress gateways for interfacing said IP network to said second 

9 telephony system; 

10 an IP telephony proxy server for selecting one of said plurality of egress 

1 1 gateways for completing said call; 

12 an IP redirect server for providing routing information to said IP telephony 

1 3 proxy server; and 

14 a network management system for receiving and storing status changes of 

1 5 destination gateways, said network management system being in communication with said IP 

1 6 redirect server. 

1 17. The system as claimed in claim 16. wherein the IP telephony proxy server is a 

2 Session Initiation Protocol (SIP) proxy server. 

1 1 8. The system as claimed in claim 1 6, wherein the IP telephony proxy server 

2 is an H.323 gatekeeper. 
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19. A method for detecting an available destination gateway from a plurality of 

2 destination gateways in an IP network for completing a communication session between a calling 

3 party and a called party, said method comprising the steps of: 

4 a) transmitting a message to one of said plurality of destination gateways , 

5 from a server to ascertain an availability status of said one of said plurality of destination 

6 gateways; 

7 • b) waiting for an acknowledge response from said one of said plurality of 

8 destination gateways for a predetermined period of time; 

9 c) determining if said one of said plurality of destination gateways is 

10 available if said acknowledge response is received within said predetermined period of time and 

11 indicates that the destination gateway is available; and 

12 d) . transmitting said message to a succeeding gateway of said plurality of t 

1 3 destination gateways. 

1 20. The method as claimed in claim 1 9, wither comprising repeating steps (b) to (d) 

2 until the availability status of each of said plurality of destination gateways has been determined. 

1 2 1 . The method according to claim 1 9, wherein if said acknowledge response is not 

2 received within a predetermined period of time, said availability status of said destination 

3 gateway is said to be oui-of-service. 
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•, 22. The method according to claim 19. wherein if said one of said plurality of 

■ 2 destination gateways is determined to be available, then said availability status is determined to 
3 be in-service. 
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